@uppy/companion: send tus response body on upload success - #6492

What

When Companion uploads to a tus destination, it now forwards the destination's final response through the websocket success payload, as extraData.response — the same field the multipart and xhr paths already fill via getRespObj.

Why

A tus destination can answer the upload's final request with a body a client needs — in our case, the upload service responds to the last PATCH with a JSON record of the finished upload (id, storage location, thumbnail, media details), so the browser can attach the media without a follow-up call. Files uploaded directly with @uppy/tus can read that response, but files routed through Companion could not: #uploadTus's onSuccess resolved only the upload URL, and the record was dropped inside Companion.

The asymmetry is already documented in the codebase. @uppy/companion-client says it in RequestClient:

payload.response is sent from companion for xhr-upload (aka uploadMultipart in companion) and s3 multipart (aka uploadS3Multipart) but not for tus/transloadit (aka uploadTus)

and #4922 fixed the client half of this — upload-success exposes payload.response.responseText as a parsed body whenever Companion sends it. This PR fills in the server half for tus.

How

tus-js-client's onSuccess receives { lastResponse } since v4; the handler reads getBody() and getStatus() from it into the existing UploadExtraDataResponse shape. No new options, no protocol change — clients that ignore extraData.response see the same payload as before, plus one field.

Testing

Verified end to end against a tus server that answers the final PATCH with a JSON body: the websocket success event now carries response: { responseText, status }, and @uppy/companion-client surfaces it as body on upload-success without changes.